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Abstract 


riiis teporl picscius .1 p..ianieific sofiwate cost esiimaium luoilel prepaieil l\it Jl*t 
Deep Space Netwoik (DsNi Data Systems implementatioa tasks. 1 lie lesmuce estimation 
cuniel mollifies aim combines a iivimbei' of eMstlnp moilels, sucli as those of tlie (jeneial 
Reseatdi C'mp., Doty Associates, IBM (Walstoit-l’clisv), Rome Air Foice Development 
Center, Umveislty of Maiylaiul. anil Rayleigh'Notileii'rntnam, Hie moilel calibrates the 
task nuiRnitmle and difliciilty, development envitonmenl, and softwaie technology 
effects fltunigh piompted lesponses to a set of aiipioxiniately 50 ipiestions. I’aiameters in 
the nunlel ate adjnsted to fit Jl’t softwaie life-cycle statistics. The eaiimalion model 
output scales a standard DSN Work Iheakdown Structuie, which is ihen input to a 
I’b'RT/Cl’M system, pioducing a detailed schedule and resouicc budget for llie project 
being planned. 



Deep Space Network Software 
Cost Estimation Modei 


I. Introduction 

The early-oii estimation of required resources and schedule 
for the development and maintenance of software lias prob* 
ably been tlic least precise aspect of tlic software life cycle, 
and yet, an orderly and rational attempt must be made in 
order to plan aiv.’i organize an implementation ciTorl. The 
existence of an orderly and rational approach implies the 
existence of a resource and schedule model that accepts as 
input the technical requirements to be achieved the magni- 
tude of the task; the physical, environmental, human, and 
management constraints assumed or knovm to be in effect; the 
histoiy base of similar and dissimilar experience; the means, 
altcrmitives, and technology avaihiblc to ilic task; and a theory 
which is capable of correlating these parameters with measured 
results. 

The least precise of such models is one wliicli relies entirely 
on experience, intuition, and luck. It is sometimes referred to 
as a “WAG", or “Wildly Aspiring Guess," (More often, the 
acronym is somewliat differently derived, but with the same 
general connotation.) When a more formalized, mathematical 
model with some statistical verification can be formulated, the 
model appellation is upgraded to “Scientific WAG", or 
“SWAG.” 

The prediction of human behavior is the problem of 
estimating events in a stochastic process governed by an 
unknown probability function. The goal of a SWAG model is 
therefore to predict the events in such a way as to produce 


minimum variance (or risk). Hie opiiniuni SWAG model can 
predict only to the limit imposed by the statistical distribution 
actually characterizing the human activity. 

The optimal SWAG model would require the precise 
quantification of all technical, environmental, and human 
behavioristic parameters, and would combine these into a 
mathematical formula producing ma.ximum likelihood or least 
mean square error results. Lacking this precise quantification, 
the best that one may hope for in a SWAG model is that it 
accommodate the principal factors affecting the estimate 
variance (or risk) in a way that reduces the variance (or risk) 
from what it would be, had that factor not been included. 

There are a number of SWAGs in existence, Fourteen 
software cost estimation models are summarized in Ref. 1 , and 
nine are evaluated for JPL use in Ref. 2, None of these, by 
itself, seemed to the author to contain sufficient range of 
application and adaptability to the diverse kinds of software 
being produced at JFL to quantify the relevant cost factors 
and risks v.'ith sufficient accuracy to be useful. Taken all 
together, however, these models seemed to possess. In their 
union, the potential for as good a SWAG as could be obtained 
at the current state of the art. 

An IBM study (Walston-Felix, Ref. 3) reported the analysis 
of 60 software projects with respect to 68 variables believed to 
influence productivity. Of these, 29 showed a significant, higli 
correlation with productivity and were included in their 
estimation model, 



A number of models repotted in Ref. I (Oeneral Research 
Cotp., Doty Associates. TRW, Ait Force Flectronic Systems 
Division, Tccolote, Aerospace t‘orp., et ah), as well as statistics 
ftom »he University of Maryland (Ref. 4), provide productivity 
data with besidil curves using many fewer parameters. 

Still other models, notably the Rayleigh-Norden Putnam 
model (Refs. b) presuppose a fe\v*p.uameter, speeine 
mathematical model, which is then calibrated using available 
industry data to provide tradeoffs between elTorl, duration, 
and 'isL 

Several models (e.g.. Wolvaton, Ref. 7) proceed to detail 
resource expenditures into the various phases of activity. Some 
of the models are fully automated, such as PRKT--.S (Ref.,S), 
SUM (Ref. ‘M. and SIH'F. (Ref. 10) The others appear to be 
calculallve, or petiiaps small piogr.tnts. 

The software cost model described in this report is fully 
amomated: it borrows and extends leatutcs from many of tire 
models above. It utili/es 7 faciot.s from the CiRU mode), 2‘) 
factors from, or smiilai to. the Walston-Felix model, and 
iircoiporates atr rnhertted (or exrstrng) code model dire to the 
airtlror, esposeil herein. U rrirlr/es the •'Pl-R’f" techntrpte to 
esirmaie the expected st/e and vartance of the software to be 
produced. U itUlt/es a modirreatiorr of the RayleiRh*Norden* 
Pitinam modii to check otr the feasthtlUy of resource 
esttmates, U applies the esittnaled effort, staff, and dirraliotr to 
a standard Work Breakdown Stnreurtc (WBS) developed for 
DSN suftwate tasks, and automatically produces a task plan 
and schedule to be used al lire mitral systemcsubsyslem 
planning, soliwate rmplemenlalton planning, or solivvare 
mittmenance planning stages of a project. 

There are dS parameters wtllUn the model which relate to 
proilnciivity, duration, stiili’ing level, doeumentuiion, and 
eomj'Utct resources. Anolher (>U parameters divide the total 
estimated effort among each WBS subtaskt an additioira! (>u 
relate total duration to subtask diuaiion. Subtask precedences 
ate adjustable, mid drive a PERT/Crilical-PiUb-iMolhod schedul* 
ing algotUUm. 

'five ovuputs of the model include eslimales and variauco 
values lor program si/e, sialf produetivily, elTort, duration, 
staflhig, documentation, and compuicr tesourccs. logcibet 
with complete scheduling earlyllate siartlihusb and lloaHimo 
data, plus a Gantt ebavt (schedule bar chart) of the planned 
activities. 

All parameters in the automated model are easily altered by 
a simple text editing process, without recompilation of the 
programs. For all its seeming complexity, the model ii.self is 
simple to use. Only a series of questions relating to si/e and 
environmcnl need to be answered. 


The ensuing sections of this report describe the model and 
its parameters, and discuss the source or deviatiou v>f param- 
eter values and other elemenis of the model. The v,ihies of 
parameters cited in this report are subject to modillicatiouand 
rermement as further calibration and usage of the model 
proceeds, lire reader iiUcrested in a eurtem set of vjrl.ie.s at 
any time .subsequent to the publieatiou of this report nwy 
consult tlie Software Specillcation Documeut (Ref 11). 

Concerning accuracy: at this writing, insurncieiu data has 
been collected from DSN projects to optimi/e the paramelers 
of the model to fit DSN productivity, duration, etc. Therefore, 
the model accuracy is tmkirown, us peitaiiriirg to D.SN 
predictions. However, the model does fit indnstiy statistics (or 
can be made to ill any of the cited source models) hy proper 
parameter selection. For iliis reason, it is felt that the fovvJIH 
data puinis that have been factored in will yield accuracy 
llgutes as good as, or perhaps better than, the other models in 
their stated environments. 


II. Model Description 

The .Softvv.ue Cost and Resource Fstimalion Model (the 
acronym .SCARliM is not used!) iwerview appears in Ihg. I in 
daia-now-duigiam Ibtnv.u. Brogram si/e and .staff produciiviiy 
factors are separately estimated and tlitm combined to 
estimarc effort, stalling, dmation, documentation, and com- 
puter resources. The model pixiduces uninilated dollar costs 
for documentation aird computer resources. Both estimated 
mean and variance values for all resources are ouipiu. 

I'stimaied values are presented in the uuiomatcd model to 
the user as advice. The user is admonislied to use these llgures 
with sufllcient ttsk biases to ensure project completion vvilhin 
a desired conlldenee value. The model then accepts any lw.r of 
the three paramelers: elToii, average staff, and dutatiun. 

These eiuties me checked against a model akin to the 
Rayloigh-Norden-Putnam model, but altered to conform with 
power-law fas to measured data. Warnings arc issued if lire 
emrios are unteasoirable. ‘fhe user may alter the input 
eslimales. if desired, for another cheek. 

Once acceptable resources and duratioi nave been decided, 
the model proceeds to produce a standard DSN software 
implomentuiion work breakdown structure and schedule with- 
oul further input from the user. 

A. Estimation of Program Siaa 

The size of the .software tusk is measured in “equivaienr 
Kilo-Source- Unc! of Executable Code (KSLEC). A source line 
of cxecurahle cod; is defined basically as a source language 
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siiUemetii I'cciipyini one physical line in the sniirce (illsplayl 
medium that results m genetatmn of object code, reservation 
of storage, or definition of data type, (’ommeats ate excluded, 
as are statements merely denning labels and eiimvalences of 
ideniillers. If several basic statements may apjrear on one 
physical source line, each such statement siunild be added 
separately into the KSU-C count. 

Source lines of new code ate weighted differemly than lines 
of reused code, in proportion to the relative amount of effort 
required to adapt the inherited code to the current task. Kveii 
deleted lines of code contribute to the programming elTori, 
and therefore Increase the ‘equivalent’' KSl.KC count. 


in which pat imeters h, c, i/, g, and h are chosen to account 
for the exfiected effort required for each correspoiuilng 
component. 

1'he assumptions with respect to each component are the 
following: 

U) New code is subjected to the entire standard implemen* 
latlon process. 

{!) The recopiiion of the reuse of existing code is made in 
the architectural phase, so code added, changed or 
deleted from modules goes only through subsequent 
phases. 


The programming tasks involved with the generation of new 
code and reuse of existing code are depicted in Fig. 2, The 
effort to specify, produce, document, and test a new line of 
code IS normalised to unity; the lines of code added, changed, 
deleted, and rctested'only contrilniie to the equivalent line 
count according to relative eflorl. The extent of existing* 
module modification is measured by ihe number of bne.s 
added m, the number changed, and the number deleted, lire 
number ofequivaleiu hires of code produced is then defined to 
be 


/, ® /. +/•/, , + (■/. I + ('/ 1 , 

*ea ,ifH- ' 'iimJ ""Wa* ilcl 


+gl., 


I’ll * 


(1) 



(.1) Added code takes the same effort as new code in 
corresponding phases where aeiivliy lakes place. 

(d) I'lianged code requites the same design and testing 
effort as new code, but less documentation and coding 
effort. 

(S) Deleied lines from existing modules require reduced 
uesign, coding, and documentation effort, and no 
testing of the deleted hue.s. 

(ti) Any module elianged Is completely retested and 
tequahned. 

(7) Deleted modules require less areliitecUiral, Interface, 
and dciailed design considerations ilian new code: only 
that coding effort required to remove the unwanted 
code contributes to the coding time; no lesiing of ilie 
dclelcd code is possible; and doeim.entelUm effort 
involves removal of entire sections of existing material 
and minor cleanup. Retesting is cowred in modules 
which interfaced with tlie deleted module 

(H) Retested unmodified code requires revalidaiion of the 
Interface design and retesting efforts only. 

The analysis in Section HID produces the following 
estimated typical values for the DSN enviroiimeiu* 
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Haeli of the eodc-si?e parameters in Fq.(2) is estimated by 
the "IMIRT" tccimique (Ref. 12). Tliis technique presumes 
that guesses for I arc gcwenicd by a beta distribution 
(Ref. 13). 


Fig. 2. Software implamantalion taska ralatad to new and inharitad 
coda activiliaB 


^I(.V) = +1 . r + I ) .v^ (1 - .v)' for 0 1 (3) 
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where /U . ) i« ihe behi fuiicuim (Ref. 14 ), 

, * * nm 
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/ 
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111 whicli / (, It (lie value ut I, yieWuv,r the iiiavunum value o! 

;'(Y) 

Oie varunee ul /. about /. „„ it 


Tfitt estiiiuiieil value fur hf,f is eoiuiHiseU of the ustuil 
weiglited suiii of she lor each parameter, imd us sliiiHlaril 
ileviaUoii IS the svtuare'W'elgliieil ro«i*suuusiiuare of the itulivi* 
dual deviaiiwia 1 he wci^its m l-q. tl) are used. 

B. Eit(nMtionofProductl¥)ty 

In this model, the produeiiviiy P Is deltned as total 
equivalent KSl !■(* there denoted / ) produced, divided hy the 
total staff effort (here denoted llO, 

P s [j.,KSirCslalT*month {10) 

A number of dat.i bases (e.g., Reis, d. 1.^, 1ft) have .shown 
that /. and It* are eorrelaied through a powerdaw relationship 


iwU) 
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!■« a given value of e, the variance oi /, is inavnuum when 



(11) 


where /’, is the aveiuge l.RiSU’C |iroduetivlty rate. The 
productivity at other values of/, is given approximately by 


giving 



Max tiwr(/.)l 
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*1 (r + 3) 


/’«’/’(/.*'** 02) 

Hie value of /*, is .set primarily by teclinolog)' and environ* 
meni. In fact, industry studies show that may vary by as 
much as 50 I as a function of such faciois, The value of a, 
however, in each environment where data is available, shows a 
' ’ telaiive constancy, at a value near unity. 


Ihe value r ” 4 is quile often use,; {Ref ft) and is adopted 
heie. liie esiunaiots adopted in the model are calculated from 
guesses loi / /,hi«,* and /.^ ■ 
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The variance value with s r ™ 2 gives a stau‘laid deviation 


of 


L (0) 

Hewn 5,20 '■ 

The dcnomimiior value of Eq. (0) usually published in the 
literature (Ref. ft) is ft, which underestimates tlie variance by 
about 1 .I'd'. 


It seems mtiUtive, all other things being equal, that /'should 
not increase as a progtanfs si/e rises: however, llie least-square 
powerdaw' Ills to data bases yield u-values m 0.0 1 (IBM, 
Ref. .1), 0.401 (Doty. Ref. 1 ), 0.0, Sft ({tniversity of Maryiaud, 
Ref. d). and 0.075 tRAlX’ Ref. 1ft). One reason for the 
indicated incteuse in productivity for larger programs may he 
I lie increased usage of higlicr lechnology to develop these 
larger programs. Whatever tlic reason, the consistency of these 
figures seems to indicate that a linear powerdaw relationship, 
if anything, is slightly conservative. 


The model ptesented here lias compensations for the use of 
higher technology. The value for a assumed by this model, 
thercrore, is unity. However, the model implenienl.ition keeps 
this value parametric, and ti can be changed, if desired. 

Several nn'rJels have contributed to the formula by wliiclt 
/', is ealcuiaied, principally iliose of GRC (Ref. 17) and IBM 
(Ref. d). The form of /'j is 

/', “/‘o^./lj (13) 


s 



where Pq « a consiaiu f!ieiurtand/i| a«rl/lj ate clitneuliy, 
(eclmologv, aiul environmental adjuitmeni faciots. The value 
of/f, Is conipuied on the basis of parameters judged by (iRC 
tobesigiiifieantf 


The comiwnent adjustments are ns follows: 

(a) lirngimge Adjustment, 

,1 » r 

LufK ^my /, 


US) 


where f„^y Is an assembly language hicior, and 
is the antount of assembly language used. 

The DSN value, 4„,, * O.n, is derived In Section 
IUF„ (iRC uses a value of^Hj. 

(b) Trme*(’rillcal-Code Adjustment,. I, 


/t * 
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where f'lvior which compensates for 

ilcsfun/code/test time tor code in which timing is 
critical, and l t tnt amount of such code. 
The DSN value. 4 ■ 0,7, is derived in Section 

mi'. The C5 Revalue is l.Ci. 

(c) CapacUy-Criticidiiy Admustmeiu. 
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where 4 errr “ factor which compensates for 
capacity-constrained portions of the program, and 
amount of code which contributes to 
the need for extra eMbrt in solving the capacity 
problem. The DSN vaiue,4 ^ = 1.0, is derived in 

Section IIIF. The GRC value is 7. 


(d) Difnctdty Adjustment, 
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where and are factors which relate to 
the relative effort required for “hard" and “easy" 
parl.s of the program, and and l.easy 
amounts of code adjudged to be "hard" and 
"easy," re.spcctively. The D%SN values, 4^^^ * 1 .2 
and 4„„, * 0.8, arc taken from data published in 
TRW reports (Ref. 6), 


(e) Requirements and Design Stability Adjustment, 


* ^'nom ^^tmnv ^many 
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Here, is the amount of code which is 

e.xtiected to derive from well-understood, stable 
requlre-’ienls. not ex|)eeted to change. Factors 
fhase ^’ihisy 0’ ‘*'1^ amount of 

code resulting from requirementr exirected to 
change moderately, but which ate kept under 
Iniscline control. Factors 4(,i„v 
from the effort and amount of code for which 
requirements are exjx’cted to produce many 
changes, but, again, will do so under baseline 
eontrol. fhe parameters and Lf^.y compen- 
sate for the aecoimnodaiion of requirements 
allowed to change freely, not bascline-eontrolled. 
Tlie values userl in the DSN model, ® K.h*;. 
i'lmity * aird « 2..^. are taken directly 
from the GIU* model. 


(f) lixperienct* Adjustment,,-! 
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Here 7^^^ is the average staff training in years, 
4vp is the training rate, and 4)« up 
trained productivity factor. The values sQ.Ob 
and 4(/; K/i ® derive from tlie GRC* model. 

The secuiul productivity adjustment taetor, /!j. derives 
from the Walston-Felix data (Ref. 2) publtslied by IBM: 


r I 'l<HD 

( 21 ) 

in wliicli N factors that correlate with productivity and their 
effects on productivity were considered. values were 
measured when factor I was applied aird contributed to 
productivity, and resulted when factor i was not applied 
and thus lowered productivity. Tlie use of .\j relates to the 
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eKteiU faaior t is present In the applieaiion being esilrnaied. 
The values used ft)r .v, are cither +1 , 0, or 1 . The parameter w 
was chosen to best fit the data collected. 


The various faciors contribiiiing to the adjustment, the 
acceptable responses, and the log-ratio values used In the DSN 
model were taken, for the most part, directiv iioin Walston- 
Felix dna. A few others have been .added, due to their 
variiibilily in the D.SN environment, The exponent value m was 
chosen to give a SOU variation between the extreme values. 


The lactors, responses, and log-ratio values used la the DSN 
model are listed In Appendix A. riie value for w is computed 
by 
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In which » l.‘t5 produces the 50U spread in prodiicfiviiy 
adjustment. The value M extends the sum siver both the 
IBM and (JRC inirdel factors. 


IBM and other duia show tlwt lire total effbri adinsiment 
may be expected to deviate, .at a given /., from the estiniiled 
value by a standard deviation factor of about » i.73, 

C. Estiniation of Implomontatllon Task Duration 

The IBM, University of Maryland, and RADC statistics 
suggest that the average durairon f requited for/, KSUKUmd 
h'siaff-monihs effort is approximated by 


E. DocumofllatkmSIiifMi and Coot 

IBM statistics showed a neatly linear relaUonslup between 
pages of docuniematton and lines of ,ode, wliereas the 
University of Maryland measured almost a square«root rela- 
tionship. DSN ex|retience over six Mark-Ill Data System 
programs reverted an exponent about midway in belween 
(0.H3). A study of Software Specillcatlon Document (SSD) 
user needs (Ref. IH) recommended tliat this document Ire 
aboui 40-.*>0 pages |rer KSU-C' for programs in ilu- 30 KSI.FC' 
vicinity. The formul.i used for lire model for the number of 
pages of documentation is 

^pp * ^1 

The model uses /), • 00 and 0.H3 to m.rtch tire DSN 
ex|)erience and SSI) guidelines. 

The documentation cost is found hy a stralj^il dollar-irer- 
page rate*. a figure of $30/page is used in the current model, 

F. Computtr iRotourcM 

IBM and TRW give statistical figures for computer time 
costs as functions of lines of code and tolal effort, and also as 
a fraction of loial cosi. The DSN, liowever, mostly has 
dedicated minicomputers for which operailonal costs arc not 
assessed to tire Implenrentaiion task on a usage basis. TRW 
does, however, also estlmaie a linear relatumship between CPU 
lime required per machine code iustrucilon of about C, ■ 2.‘<.2 
CPU liours per thousand instinction.s. 

Tire DSN model computes CPU resources as 


r * r, i/‘ ( 23 ) 

where 7’, is the l*KSl.HC average duraiion, and /, is a 
time-factor exponent fmind from industry statistics. The value 
used in lire DSN model, 7*j « 4.H, was adjusted to fit limited 
available DSN daia, and /, « O-dSo was lire average power-law 
for the more extensive IBM. RAIX’, and GRC daia. 

D. Avurap* Staff 

Tlio average staff, in persons, resulls from manipulation of 
the duration equation, 


Ihe lilgher-ordcr-languagc expansion factor, * 2.4, used 
ill tlie DSN model is the GRC ngure. based on JOVIAL, The 
exponent wiliie piveii by Walston and Felix (who 

give dollar costs, rather tlian CPli lime), is adopted to accoiml 
for the general trend of CPU time with program size. 

If CPU dollar cost Is relevant, the model computes tliis at a 
straiglK dollar-per.CPU-lumr figure (zero in tlie DSN model, 
Inn a parameter is available for other applications). 


_ K 1,4 /r riav V«rlinc« Computation 

' ^ ) Wo assume in this model that measuremonts or values of a 

quantity .v for a given x satisfy a power-'aw formula of (he 
Tlie staffing exponent, 1”4® 0-b44, implied in file DSN form 
model compares wiili measured values averaging 0.02‘) across 

industry. y a kx'’ ( 27 ) 
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in which )' is a known, 11x«d vitinc, but k vxhiblis some 
slatisiical Uisiribuiion about a besi*power>law ill, 

,»-o * ( 28 ) 

The values of Hq aiul i’ arc chosen to minimize tlie logatitlimic 
error over the observed data. 


N 

err [ 1 nO') I .v) ) » (In )) ^ I ii ,)•’) (2‘)) 

I I 


H. ModifM R«yMgh*Nord«n>PutfMin Model 

Guided by the SWAG-estimated values, the uses of the 
model enters the effort, duration, and staff parameters 
intended for use. As a check on reasonableness, comparisotts 
of these parameters with the Raylcigl»*Norden-l’utnam model 
are made. However., some adjustments in this model have been 
made in order to make it lit the average power-law variations 
dc.<!cribed above. 

The basic differential etinaiion describing tite average work 
effort, u', is taken to be of the form 


The variation in ,v is expressed as a (X/) -factor to be applied 
to .j'q at a given x. 

If, in a particidar instance, there is uncertainty about the 
value of ,v, then the variation is described by 

i’flr(ln.v) = /;' (in +>' In (30) 

\ ^01 

where 1 n (x^) is the mean of 1 n (.v). 

If k^ and x', arc dcllned as those values such that 


k 

In* ' « /! 
'^o 


In* * !•: 

' ("'■ r) 

•'o 

V -'or 


then we ean write 


w' * At'' {K- w) (34) 

in which w * w(0 is the cumulative effort expended up to 
lime / (months), K is the total life-cycle staff-months effort, r 
is an exponent that accounts for learning curve and sets the 
“pace” of the work, and /I is a constant sealing time. 

Norden and Putnam assume /•- I (a linear learning curve): 
however, this value of r is not consistent with the observed 
power-law relationships between L, 7\ and IP. 

The solution to the modified equation is 

,v.A:jl-cx,,[-(4-^)(.L)"']j (35) 

where the value A has been replaced by ' , in which t^ 
is the value at which w' is maximum (time of maximum 
staffing). 

We use '/’ to denote the time of acceptance test completion 
and transfer to operations (in montlis), whence w (7”) » IP. 
Then 


y ■ k^x" iX/k^) 


where k^ is a standard deviation factor 


(32) 



A'j = exj/ 

I'aclors such as this are applied in the model to each power 
lasv, using k^/kQ values measured from industty slaiisties.and 
,v,/,Vq values assumed to be one-sigma estimations of the 
,v-paramelcr. The .v-parameter in the model ultimately derives 
from tiie program length, /., whose variance was addre.ssed in 
Section 1 1 A. 


As in the Putnam work, a "difficulty index," D may be 
defined as 

Kr 

D (37) 

and a "difficulty gradient factor” can be similarly denned as 

VD = {ry\)M^ (3.8) 

^‘o 


[( 


In* - ~ + 1»* In* 




(33) 


B 


These reduce to the I'utnam expressions when r«i. Note: 
IHilnain expresses these values using time un>ts of years, so 
comparisons rerjuire a scale change, 


For a given h, the ratio qtp sits the lime vs effort tradeoff 
rciationship, Use of tire factor f* q{p» -log in\IW)llo% 
iTJT) |)crmils p and <i to be expressed as 




V0p„, • n'*' w 


(39) 


The number of lines of code is taken to be of the same general 
form as Putnam’s “software equation,” 

/. * £v Ki’ (40) 


„ , I 
^ «{!+/,/) 

(44) 

/ 

^ (»(l+//) 

Tire model contains an input parameter IP, /IP * IP, , defmed 
to be the effort ratio for which 7\IT* Ml. This parameter is 
used to specify the value of /as/* logj (IP,/j ). 


(Putnam takes 4/3, a 1 :4 relationship,) Tlic values 

(ar p and q used in the DSN software cost model are chosen to 
si.tisfy both power-law productivity constraints and time- 
effort tradeoffs. 


The equation for / is thereby 

/ D «/(''+ 1 ) 

L * IP'/" (45) 


Tlie ratio IP/A' is lire implcmentatkm-cfTort/lolal-lifc-cycle- 
elTorl ratio, which Putnam estimated to be constant, at about 
0.05, and NASA measurements (P.ef. 14) found to be about 
0.H8. Such ralii's set the proporliot.'ality between T andr^ to 
produce the equations 

L ~ 0^, r> “ Cpipp^'^r" = s'> (41) 

for an appropriately denned technology constant related to 
the productivity coefficient/', evatiiaied by lire mode!. 

We may use the power-law formula lor L and the definition 
of D to eitminate T, V/heu difficulty is held constant at a value 
Dq corresponding to the power-law, or “average difficulty” of 
projects, wo find that the following relationship must hold; 


and the expression for productivity P as 

(D w/pri) 

P ^ iP^A^A^^^l\~) It'fW ' (46) 

If f=^q!p were set to the Putnam value (viz., 4) then a value 
IP, ,j = 1 6 would result. While the best value of / for DSN 
tasks has not been determined, the consensus of managers and 
programmers is that a 16:1 effort factor to reduce duration by 
a factor of 2 is too extreme, and not within their ex|)cricnce, 
Ratlicr, a IP,^j = 1,5 value is probably closer to actuality in 
the DSN environment, This assumption produces the values 

/ = 0.585 


I 

a 


sst 



(42) 


p = 0.828 


Use of the power-law expression for average T similarly 
produces tlie relationships 

/ R -.L, 

•'f r+ 1 


(43) 

T ^0 
= (r+ 1) -- 


r = 0.484 

t’p = 0.0621/(A,/lj) 

Tim value IP/A' = 0.88 mentioned earlier produces 
T 

1.53 

' I 

= 0.788. or = 7.06 
= 0,169/r,or = 182/J 


(47) 


( 48 ) 
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Difficulty ant) grinlient calculalions are not currently used In 
the model, however, 

When L and IV arc given, fand S arc then given by 



When L and fare given, IV and Sate 



vherc /'{• } is the probability function. That is, the confi- 
dence level is the probability that both effort IV am/ duration 
7’arc not exceeded. 

Under the presumptions that the conditional densities 
p (f I IV, h) and p ( IV I IJ) are log-normal (which are fairly 
well borne out by RADC data, sec Ref, 16), and that p {L) can 
be estimated by a log-normal density as well, fiien the 
confidence factor is readily calculated. The log of the software 
equation provides the conditional mean foi log (T) in the first; 
the log of tlic power-law formula provides the conditional 
mean for log IV in tlic second; and the code size estimator 
provides the mean of log (/,) in tire third. The result is the 
integral 

C(IV, T) » r [1 + erf (M + I'.v)] exp (-.v^ ) dx (53) 

2(7T) ' 

in which 


and when L and S arc given, IV and 7’arc 


IV » 



i/{p+«) 


T = 


S 


(51) 


That is, only one of the average IV, T, S parameters need be 
specified for a given /..The others can then be computed (and 
arc in the model). 



(54) 


If any pair of the IV, T, S parameters is proposed, the 
lincs-of-code value determined from the “software equation” 
represents the average number of lines of code that can be 
supported by the proposed resources. The difference between 
the size-model estimate and the software equation estimate is a 
margin on which confidence levels nwy be calculated, 

One should note, liowcver, that the software equation does 
not remain valid for tasks so small that average staff drops 
below unity. In this case, we revert back to the power law 
equation to yield the needed effort and solve for T and S from 
the rciation IV « TS, 


K - 1 + 


„ 2 . 2 
p 


(2 = Y + 




Z 


= e+ 


p'^s 

(p's 


2 

W 

2 

T 


Confidence in completing the software task within 
resources and budget when staff is variable is 


q;iv,7’) = /^U<r.w<W} (52) 


The values / and w are duration and effort values on the 
software equation curve producing the expected number of 
lines of code; s^, s,^/, s,|., represent the standard deviation in 
log (/,), log (IV), and log (T), respectively. 
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The r(IK7*) appears to be a I'liiicikm of arbitrary param* 
eters t,w on the curve Tire triple, 

represents the point from whieli nurgins me ineasureil to 
the resource values to be used in the project. The 
model chooses re,f to inasimi/e (’{h'J'). The optiinuni values 
of re and t satisfy the equation 

11 +eif(/'’.v + (/>')] exp I ^ “r ^ ) 

» //ll r erf (J.v + A/)) exp ( {SSI 

where 



^A]uation (551 is solved by Newton's method, siibiect to the 
constraint log + f/s^v and the confidence 

integral is evaluated by numeric integration. 

I. Standard Work Braakdown Structura Modat 

The DSN Data Systems Section has adopted a standard 
WBS formal for its software implemenuition tasks. The format 


of sublasks is shown in Table 1 . The table also shows the 
average reported effort in .11 recent upgrade tasks for each line 
item, adjusted for future tasks based on an analysis of the 
problems encountered. Requirements and subsystem design 
resources were not reported with the subsystem implementa- 
tion activities; however, estimates for these liave been factored 
into the WlkS model, 

The model iierrnits selection of the stalling point for WBS 
generation: at the System/Subsystem iMinctional Require- 
ments (inU)) commencement; at the beginning of the Soft- 
ware Requirements Definition (SRD); or at the beginning of 
the Software Design Dennition (SDD), at which time the 
soflWMie architectural considerations are dovcloiwd. 

Once a starling point has been selected by the user, the 
model apportions staff effort over the remaining sublasks 
(using perceniage parameters in the standard WBS data base), 
and calculates subtask durations (also via percentage figures in 
the data base) to conform with the selected oserall effort 
duration. These percentages are currently chosen la product a 
relatively constant effoit prollle over the implementation 
project. This prollle is a trend in the small DSN efforts 
currently under way. The (rcrcentages are alterable, however, 
to lit any assumed prollle for other tasks. 

The standard WBS data base also eoiuuins preeodeiice 
information among sublasks, whicii is used by ihe I’liRT/Cl’M 
scheduling algorillim. Such precedences were set by logical and 
management criteria to form a rational progression of aciiWiies 
and milestone.s commensmale wiili DSN standard software 
implementation pracliecs. Preecdcnecs for each task are 
s(K'eii1cd in tile form of the decimali/ed numher of the lask(s) 
wliich nnist compleic before llial parlicular task may begin. 

All items in the standard WBS data base can be altered to 
fit anollier projcei by a mere text odilint' process. 


•i. Operational Modes 

Tlie DSN Software Cost Model software lias a size/ 
prodiiciivily estimation mode, wliieli is optional; if esiimaies 
of staff effort, average staff size, and task duration are known 
a priori, ilie estimation mode may be skipped. 

Regardless of the means by wliicli amount of code staff 
effort, average slaffing, and project duration are estimated, 
these figures are used lo calculate a coiifideucc level. The user 
may adjusl estimates, as desired, uiUll a suitable sol of resour, 'e 
parameters is obtained before proceeding to tlie .schedule 
gciierailoir process. 


1 ! 



Tnbtol. Standwrt wortt ^nt Memn rtnict w 


Task ITTort.'\' 

Duration, ‘V 

0 Start 

00 

00 

1 System pkins. rcqaircmenls, and design 

Of- 

0.0 

1 1 Udine subsystem requirements 

2.5 

3.2 

12 I HU 

00 

00 

121 Write all sections 

0.7 

0.9 

12 2 I dtt and release I RD 

0.3 

04 

13 Level It review 

05 

0.6 

1 .4 Define system ardmeeturc 

3 0 

3.9 

1 .t I RI) 

00 

00 

15 1 Write all sections 

0.7 

0.7 

15-2 I dit amt release 

0.3 

04 

16 Level ('review 

OS 

06 

2 Software pi, mmiiR and reqiiiremenis 

00 

00 

2 1 Deline software requirements 

4 0 

5.6 

2 2 SRD 

0.0 

00 

2 2.1 Write all sections 

07 

07 

2 2 2 Ldii and release 

03 

04 

2 3 fevelD review 

04 

0 6 

3. Software arclmectnre ami design 

00 

00 

delinition 



3.1 Define aoltware arcliiieelurc 

5 0 

7 2 

3 2 SSI) 

00 

00 

3 21 Write all sections 

06 

0.6 

3.2.2 I dii and release 

0.3 

0 4 

3 ,3 System intetface design 

3 6 

3 6 

3 4 level I- review 

04 

0.6 

4 Sottware deiaited design and 

0.0 

00 

production 



4 1 SSI) 

0.0 

0.0 

4.11 Write Sections 1. 2, 3 

t.o 

to 

4.1 2 Wriie Section 4 

30 

4.4 

4.1.3 Write Seetion 5 

70 

7.0 

4 1.4 Write Seetiun 6 

0.7 

0.7 

4 1.5 Write Seetion 7 

1.5 

J.5 

4 1.6 I’dit and release 

0.9 

0.9 



Ta.sk 

1 ffort.'t 

Duration, 

4.2 

SOM 

00 

0,0 


4.21 Write preliminary draft 

13 

19 


4 2.2 Complete all sections 

IS 

1.5 


4.2 3 I dif ami release 

06 

06 

4.3 

IliglUcvel design review 

04 

0.7 

4.4 

Mod h production and inlefration 

0.0 

00 


4 4.1 l .seculivc and control 

2.9 

5.6 


4-4 2 I/O modules 

29 

5.6 


4.4 3 Interlace handlers 

2.9 

5.6 


4 4 4 l•lmcllonA 

29 

5 4 


4 4.5 f uiKTionl) 

2.9 

54 


4.4.6 I'lmctlon C 

2.8 

5.2 


44.7 lunciimiD 

2.8 

5.2 


4 4 8 l unclionl' 

2,8 

5.2 


4.4.9 l•unctloll F 

2.8 

5.2 

4.5 

Spcci,il tasks 

0.0 

0.0 


4.5.1 Support software 

2.0 

2,0 


4.5.2 Other 

10 

1.0 

4,6 

Acceptance reailiness review 

0.) 

0.7 

5. Software test and transfer 

0.0 

0.0 

5.1 

Veriiication tests 

4.5 

8.1 

5.2 

Contingency 

4 0 

4.0 

S.3 

SIT 

0.0 

0.0 


5 31 Write all sections 

2.3 

2.3 


5-3.2 Edit and release 

0.4 

0.4 

5 4 

Acceptance tests 

3 3 

4.1 

5 5 

Deinonstralion tests 

3.S 

4.8 

5 6 

rransler, CDL to COi 

12 

1,6 

6. Management tasks and milestones 

0.0 

0,0 

6 I 

CDI' adivitie.s 

60 

6.0 

6 2 

Develop preliminary budget 

0.5 

0.6 

6.3 

Develop system implemcniatiou 
plan 

0.5 

0.6 

6.1 

Draft software implementalion 
plan 

I.Q 

1.4 

0.5 

Revise implementation plan 

2,0 

2.9 


Output is ulTeictl on hard copy or computer files, ,it user 
selection. Schedules are output beginning with FRD, SRD, or 
SDD activity. 

K. Risk-Bias Computation 

The size and resource estimates produced by the model are 
mean*estimale flgures; however, variance rigures are also given 
for risk-bias computations, as appropriate. If a schedule is 
generated using the mean estimates given, then the conlldencc 
factor for performing the implementation on time and witliin 
budget is only about 2.'>T. That is, only about one-(|uarter of 
the projects using the mean estimates .should ex|)cct to deliver 
within schedule and budget! If a project desires a confidence 
factor higher than 25'T, then resource estimates must be 
increased by some amount to produce the higher confidence 
level. 


III. Selection and Calibration of Parameters 

This section contains a data base of statistics and computa- 
tions used in the foriuulation of the DSN Software Cost 
Model. 

A. Productivity Statistics 

The following formulas represent best-m parametric models 
of observed data on KSLFC vs effort. In most cases, the unit 
of measure was not actually KSl.EC, but something probably 
linearly related, such as delivered source lines (including 
comments) or object instructions. 

It' “ 5.2 h" '’’ (IBM) 

Id » 1 .27 (University of Maryland) 
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Fig. 3. Itniuilry •■llmatvt of affort vs source lines of code delivered 


If “10.1 

(GRC, high-ordor languages) 

It' = -1.86 

(RAIX’) 

It* = $25 L' ®®’ 

(Doty) 

niCvSC are shown in Fi;^. .1. 


‘I'he exponent for L in the DSN model was chosen as unity 
for the following reasons: (1) the pro.\imity of all the mea- 
sured e.xponent values to unity. (2) tlie wide .scatter of points 
in each case, and (2) the intuitive feeling that productivity 
cannot rise, all other things being the same, when the program 
size increases. 

B. Staff Size Statistics 


Staffing level industry stai 
among best-fit models. Some 

iialics yielded least variation 
of the results arc 

S » 0.54 IF® *^ 

(IBM) 

» 0.40‘> IF“>'^’'‘' 

(’) 

S * 0.198 IF”*’®* 

(University of Maryland) 

= 0.196 IF"-’^ 

r) 

5 « 0.989 h 

(RAW) 

« 0.369 IF®‘‘*^‘* 

(*) 

* 0.388 

(*) 


llie Htjuros asloiiskecl (*) mo coinpuloil Iron* other 
measured siaiislies by the same company listed. For example, 
if project dmaiicii was given as a Amotion of effort IF, then 
the staffing coidd be computed by S® M'/7’for comparison to 
the best-tit data, 'fhese staffing best-fit data are plotted in 
Fig. d. 



Fig. 4. Average staffing required vs project effort 
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'Hie DSN model cominilc’s S fro»» effort It' and duration T 
directly, 



The DSN elTorl-e.vponent was cominited from a least* 
squares lit to at) equal number of points chosen from each tit 
above, as well as the implied durations taken from staffing 
statistics in Section IIIB, The multiplier coefficient was taken 
to fit observed DSN data. 


C. Froi«ct Duration Statlttics 

Duration statistics seem to produce sliglitly different effort 
exponents across the industry estimates, but seem to converge 
in the 100 staff-months effort region. The fits are 


r - 2.47 IP'’** (IBM) 

» 3.1,1 (*) 


T - 5 .1 0 IP”-^ (University of Maryland) 

a 5,1 0 ipo Jor. 


T ~ I. (KAIX’) 

~ 3.50 |p0.as8 


As in the previous section, the figures marked by asterisk 
(*) are not direct measurements, but computed from diiect- 
meastirement power-law fits. These duration data are pre- 
sented in Pig. 5. 



Fig. 5, Average duration of software projects vs the effort required 


D. Effort Ftciort of Inhoritod Cotfo 
Utiliiation 

The assumed effort factors for the utilization of existing 
code are shown in Table 2. The standard WBS entries arc 
.shown, along with the estimated effort lequired for each in a 
one-sialT-year project (242 staff day.s), The entries for "New 
Module" are the numbers allocated to each activity, adding up 
to 242; that is, if the project were to develop only entirely 
new code, all 242 staff-days would be used. 

For each other column, the entries arc the estimated 
resources spent in each activity, as if the entire project were 
totally involved with only that activity heading the column, on 
the same amount of code as addressed by the effort in column 1 . 
riie ret|uiicd effort ti' be applied is scaled from the relative 
amounts of all code to be utilized. The "equivalent’' number 
of new lines of code for any of the cohmuis is found by 
multiplying the work factor times the number of lines 
hypolhetically being processed. 


E. H)gh-L«v0l Languag* Adjustnwnt 

The statistics for usage of high-level laitguages vs assentbly 
language are widely diverse in their effects on project effort, 
GRC reports (kef. IS) best-fit curves to measured statistics of 

IP* 0,38 (assembly language sources) 

IP* 10.12 (high-order lattguagc source'*') 

The (♦) statistic is derived fronr the measured ratio of object 
instructioirs to high-level source statements. These two equa- 
tions suggest nearly a 1 :1 ratio of effort on a source line basis. 
However, GRC also proposes a 4.5:1 cost factor in their 
Military Sales Software Cost Model (Ref. 17). Therefore, an 
analysis similar to that of Section 3.4 was undertaken to 
estimate the high-level vs a.ssembly-language tradeoff. The 
assumptions were: 

(a) Design, coding and unit testing activities would increase 
proportionately to the code-expansion ratio of the 
language. A value of 2.4: 1 (GRC) was used, 

(b) IXicumentation of the code would also increase iir the 
same ratio, to keep the same relative degree of detail 
(pages/KSUiC). 
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TaM«2, InlwrHwicoctovffcMiraqdrMlwntMlifiMlM 


Avtiviiy 



Changed module 




New 

module 

Added 

code 

Deleted 

code 

Changed 

code 

Same 

code 

Deleted 

module 

Retested 

code 

Ket|uirements and design 








IRl) phase 

6 







1 DD phase 

7 







SHI) phase 

10 







phase 

13 

13 

4 

13 

4 

4 


SIS activity 

10 

10 

3 

10 

3 

3 


SSU pliase 

22 

22 

5 

6 

5 

5 


Special 

(. 

6 


3 




Otliet 

3 

3 


1 




Coding 








SSI) phase 

23 

23 

3 

7 


3 


Special 

6 

6 


3 




Other 

4 

4 


2 




Twiing 








Integration 

12 

12 


12 

12 



Verification 

12 

12 


12 

12 



Contingency 

2 

2 


2 

2 


2 

Aecepiaiicc test 

10 

10 


10 

10 


to 

Deinoiisitalion 

U) 

10 


10 

U) 


10 

Documentation 








IHl) 

3 







1 1)1) 

3 







SlU) 

3 







SDl) 

3 

3 

1 

2 


1 


SSD 

31 

31 

4 

10 


4 


SOM 

3 

3 

1 

2 


1 


SIT 

6 

6 

1 

3 


1 

2 

M anage men 1 








I'lU) review 

2 







I'Df, review 

1 







SRI) review 

s 







M.iiugeineiil plan 

7 







SDl) review 

3 

3 

1 

1 

1 

1 


lligli level design 

1 

1 

1 

1 

1 

1 


review 








Aeceptanee review 

1 

1 

1 

1 

1 


1 

Transier 

1 

1 

1 

1 

1 


1 

CDt' SSD pliase 

9 

0 

2 

9 

2 

2 


t'l)l test phase 

3 

3 

1 

2 

1 


3 

lOlill 

242 

194 

29 

123 

65 

26 

41 

Inrctor 

1.0 

0.80 

Q.12 

0.51 

0,27 

0.11 

0,17 


(c) Acceptance tests, being lunctional tests, would be tlie 
same for the two. Tlic reduced number of functions to 
be tested per KSLUC of assembly code as compared to 
tlie higirer-ordor language was fell to be negated by tbe 
larger number of errors likely to be found. 

(d) Requirements and architectural design tend to be 
top-level activities depending on numbers of functions. 


Tlie number of functions which can be provided i>er 
KSLUC is less in assembly language by the language- 
level factor. Mence these activities should lake the same 
effort on a per-function basis. 

Table 3 shows the estimated resiource budget based on a 
one-staff-year effort, high-order language effort. Tire factors 
above have been applied to the individual subtasks to arrive at 


IS 



TaMtS. AsMintolylanguagatftortraqukWMfHMtinwlM 


Acllvliy 


IRD 

Start 

SRD 

start 

SDD 

Start 

Requirements and design 




i'RD phase 


0 



lOD phase 


7 



SRD pha.se 


to 

10 


SDD phase 


13 

13 

13 

SIS activity 


10 

10 

10 

SSD phase 

X 2.4 

53 

53 

53 

Special 

X 2 4 

14 

14 

14 

Other 

X 2.4 

7 

7 

7 

Coding 





SSD phase 

X 2.4 

55 

55 

55 

Special 

X 2.4 

14 

14 

14 

Ollier 

X 24 

10 

10 

10 

Tesllne 





Integration 

X 2.4 

29 

29 

29 

Verification 

X 2 4 

29 

29 

29 

Contingency 

X 2.4 

5 

5 

5 

Acceptance test 


10 

10 

to 

Demonstration 


10 

10 

10 

Documentation 





IRD 


3 



IDD 


3 



SRD 


3 

3 

3 

SDD 


3 

3 

3 

SSD 

X 2.4 

74 

74 

74 

SOM 


3 

3 

3 

sn 


J2 

12 

12 

Mamigement 





t'RD review 


2 



I’DD review 


2 



SRD review 


5 

5 


Management plan 


7 

7 

7 

SDD review 


3 

3 

3 

IligI) level design review 

J 

1 

1 

Acceptance review 

1 

! 

1 

Transfer 


1 

1 

1 

CDF SSD phase 

X 1.3 

12 

12 

12 

CDF test phase 

X 1.3 

4 

4 

4 

Total 


421 

398 

380 

I'aetor 


1.74 

1.82 

1.89 


the estimated assembly language overhead, Tlic criccts of the 
three permitted starting points arc shown. 

F. Capacity and l iming Conatraint 

Adjuatmant 

Capacity*conslraincd effects on required software effort are 
also diverse in industry, and did not seem to fit with DSN 
experience. IBM published (Ref, 3) a 3,8:1 ratio for a severely 
constrained task. GRC reported (Ref. IS) a 5.15:1 ratio and 
recommended an 8:1 ratio of effort be used in its Military 
Sales Model (Ref. 1 7). 


Capacity constraints can ofieit be relieved by program 
optimisation or segmentation, when mass storage resources are 
available, but timing considerations then also sometimes 
become a factor, and TRW estimates a 2.5:1 factor In effort 
for such timing constraints. GRC concurs in tills figure, TRW 
also estimates a 3:1 increase in effort to. real-time programs 
over sequential programs. 

Inasmuch ns capacity and timing constraints often require 
coding in assembly language, it was felt that the tlirce were 
correlated in the same data and that the effort factor of all 
three taken simultaneously was overcompcnsaiion, Tiie DSN 
productivity on tiie Mark III Data System (10 source lines/day 
in assembly language, with real-time and severe capacity 
constraints) tended to fitvor this hypotliesis. 

Tables 4 and 5 are estimated resource budgets for capacity- 
and timing-contrained developments. Since these factors 
directly affect code design, coding, and testing, the cmpliasis 
of the extra effort is applied in these subtasks. 

G. DSN Docuimintation Statistics 

The documentation page count of six Mark III Data System 
tasks representing over 100 KSLEC produced data presented 
in Table 6. Tiiese data gave bcst-fil power-law statistlci of 


^iiiw 

s 

6.39 

(X/1.50) 


- 

2I.3 4“““'» 

(X/1.63) 


as 

15.3 4®'’” 

(X/1.21) 

^ssn 

s 

j 36 4 0.832 

(X/j .21) 

^^ssr 

as 

7.71 4*'®® 

(X/I.6I) 

^tat 

SB 

175 40.829 

(X/1.21) 


It was generally felt, liowever, that the SRD and SDD 
documentation represented by these figures was not detailed 
enough, whereas the SSD was too detailed in some areas, and 
yet not detailed cnougli in others, A study (Ref. 18) 
recommended about 46 SSD pages/KSLEC (without listings), 
down about 43% from tire average of 80 pages/KSLEC 
actually produced for the SSDs, or down about 33% from the 
total. 

The power law curves above were therefore adjusted up 
10% for the SRD and SDD, and down by about 43% for the 
SSD to arrive at the recommended figure 

^ror “ 120/,®*” 


(X/1.2) 


TabI* 4. Capacity conatraint cHoft raquIrwiMnl aatimalaa 


TaWa S. Tima critical moduia atfurt aatimalaa 


ActJivlty 

ii 

jjHQIII 

HE EDI 

SDD 

start 

Requirements «(h 1 design 




1 R» phase 

b 



IDI) phase 

7 



SRI) pitase 

10 

10 


SDD phase x 2 

26 

26 

26 

SIS aetlviiy X 2 

20 

20 

20 

SSI) pluise X 5 

110 

110 

no 

Special X 4 

24 

24 

24 

Other X 4 

12 

12 

12 

Coiling 




SSD phase X 2 

46 

46 

46 

Special x 2 

12 

12 

12 

Oilier X 2 

8 

8 

8 

Tesling 




Iniegraiion x 2 

24 

24 

24 

Verification x 2 

24 

24 

24 

Contingency x 2 

4 

4 

4 

Acceptance test x 2 

20 

20 

20 

Oeinonsiratlon x 2 

20 

2tl 

20 

Uocuinentation 




IRD 

3 



11)1) 

3 



SRI) 

3 

3 


SDD 

3 

3 

3 

SSD 

31 

31 

31 

SOM 

3 

3 

3 

SIT 

6 

6 

6 

Management 




I RD review 

2 



11)1) review 




SRI) review 

5 

S 


Management plan 

7 

7 

7 

SDD review 

3 

3 

3 

High level design review 

1 

1 

1 

Acceptance review 

1 

1 

1 

Transfer 

1 

1 

1 

CDF SSD phase X U 

12 

12 

12 

CDF test phase x 1,3 

4 

4 

4 

Total 

463 

440 

422 

Factor 

1.91 

2.01 

2,1 




Activity 


FPU) 

Mart 

SRD 

start 

SDD 

start 

Requirements and design 




I RD phase 


6 



F DD phase 


7 



SRI) phase 


10 

10 


SDD phase 

X 15 

20 

20 

20 

SIS activity 

X IS 

IS 

IS 

l.< 

SSD phase 

X 3 

6b 

6b 

66 

Special 

X 3 

18 

18 

18 

Ollier 

X 4 

9 

9 

9 

Coding 





SSD phase 

X 2 

46 

46 

46 

Special 

X 2 

12 

12 

12 

Other 

X 2 

8 

S 

8 

Testing 





Iniegraiion 

X 2 

24 

24 

24 

V'erification 

X 2 

24 

24 

24 

Coniiiigency 

X 2 

4 

4 

4 

Accepiance test 

X 2 

20 

20 

20 

Demonstration 

X 2 

20 

20 

20 

Documentation 





IRD 


3 



FDD 


3 



SRD 


3 

3 


SDD 


3 

3 

3 

SSD 


31 

31 

31 

SOM 


3 

3 

3 

STT 


6 

6 

6 

Managemcnl 





FRD review 


2 



IDD review 


2 



SRD review 


5 

S 


Managemciit plan 


7 

7 

7 

SDD review 


3 

3 

3 

High level design review 

1 

1 

1 

Accepiance review 

i 

1 


Transfer 


1 

1 

1 

CDl SSD phase 

X 13 

12 

12 

12 

CDF test phase 

X 13 

4 

4 

4 

Total 


399 

376 

358 

I'aclor 


1.649 

1.72 

1.71 


»■ 
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Tublt 6. DSN documtnialion ■tallaUbt 


Subi> stem 

ksm 

. SRO 

SOO 

SSI) SOM 
il'ages) 

sn 

leial 

t’l*A Ol' 1 A 

214 

6) 

12U 

1474 

195 

451 

2784 

1 1’A OP 1 

•m.t 

aj 

58 

5678 

255 

756 

4748 

MI»A OP 1) 

15 l 

22 

55 

414 

85 

55 

Itl2 

DSl 0P4’ 

? 

18 

58 

580 

36 

52 

524 

MONOPC 

122 

It 

75 

1518 

128 

162 

1642 

(Ml OPl) 

it 8 

17 

25 

1541) 

45 

66 

1541 


The SRI), SDI), and SSI) reeoininemled best-fit si/es aie: 




•j 1 j 0.492 

(H/l.S) 

^hnt) 

e 

2.5.-I Z.® '**'’ 

(X/l.O) 

^hsi) 


7.x .4 

{K/1.2) 


D 

15.5/.“’^’ 

(X/I *2) 



7.71 



IV. Typical Example of the Model Operation 

TIte sol’twarc prutatypc implenieniatiim ul' the DSN Soft* 
ware (‘ost Minlel was prograinined for the JIU, Auloiiiaied 
Oriiee Data Ceiiier/Terminal Work Station (AODt'/WS, 
Ref. 20), svhieh iittli/es a /.-SO CTU,(>dK-by{es RAM,dtslettc 
storage, and a Cl’/M-coinpaiible operating systeni. 

The user ntercly enters tire program name (SOl'TCOST) 
and answeis prompted riucsiions. A blank form is available 


(see Fig. 6) for data entry by an oper.ilor, should the user so 
desire. The example on the completed form shown in Fig, 7 
produces the outputs shown in Fi^. 8 through i 2. Outputs are 
selectable; all or none can be generated. 


V. Summary and Conclusion 

llic .Softsvare Cost Model reported here is the first of a 
series ol refinements. As the model is used and us performanee 
data arc eollected, no doubt changes will be made: adjust- 
ments of patatneters, alterations of formulas, modilleations of 
formats, added and deleted input requirements, additional 
kinds of outpi'ls, and so I'oith. Oi'e extension currently 
eimsioned is the automated transfer of the WBS data base 
generated by tlie mode) into the WBS-b.ised project control 
system currently used in tlic D.SN Data Systems implementa- 
tion tasks, by means of networking the software model host 
computer witli tlie project control system host. 

If tlie model presented seems complex, it ts justly so, for 
the factors which affect human performance are generally 
complex and uirpredietahle, except in statistical terms. One 
sample function chosen from a siodtastlc ensemble is hardly 
ever “average" or "lypiuMf'' One nrust expect variations 
between actual behavior and pjedictions by the model. 

The directions for the future are to refiire tire model lor 
greater accuracy (wlllim fire human iK’iformanec estimation 
capacity limits), to extend the utility >rf tlie model throughout 
the entire software life cycle, and to provide the basis for 
indicating needed new coinpuier technology, software 
methodology, and tools. 


ifl 





TITLES 

ECR/ECOi 

SUBSYSs 


E triK'TK ■c-jwrawc 3» 


cr"j 

PROG. ID, I 
Dat« Estiroateds 




Answer the following items to the beat of your eatimation. 

1. How much new code is to be produced (completely new modules)? 

Maximum value, kilo-linos executable source (991 confidence level) ? 
Expected value, kilo-lines executable source? 

Minimum value, kilo-lines executable source(99l confidence level)? 


2. How much code exists in modules requiting modification? 

Maximum value, kilo-lines executable source(99l confidence level)? 
Expected value, kilo-lines executable source? 

Minimum value, kilo-lines executable source (991 confidence level) ? 

3. How much cod 2 will be deleted from those existing modules? 

Maximum value, kilo-lines executable source (99% confidence level)? 
Expected value, kilo-lines executable source? 

Minimum value, kilo-lines executable source (99% confidence level)? 

4. How much code will be added to these existing modules? 

Maximum value, kilo-lines executable source (99% confidence level)? 
Expected value, kilo-lines executable source? 

Minimum value, kilo-lines executable source(99% confidence level)? 

5. How much code will be changed in other ways in these modules? 

Maximum value, kilo-lines executable source (99% confidence level)? 
Expected value, kilo-lints executable source? 

Minimum value, kilo-lines executable source (99% confidence level)? 

6. How much code will be deleted as entire modules from existing code? 

Maximum value, kilo-lines oxouutable source (99% confidence level)? 

Expected value, kilo-lines executable source? 

Minimum value, kilo-lines executable source (99% confidence level)? 

7. How much of the remaining existing code must be retested? 

Maximum value, kilo-lines executable source (99% confidence level)? 

Expected value, kilo-lines executable source? 

Minimum value, kilo-lines executable source (99% confidence level)? 

0, Expected percentage of code to bo developed actually delivered 

(C-90, 91-99, 100)? 

9.. .HOW many differcni; kinds of input/output data items per 1000 linos of 
new or modified codeOOO, 16-80, 0-15)? 


10, Overall complexity of program and data base architecture 
(high, medium, low)? 

11, Complexity of code logical design (high, medium, low)? 

12. What percent of the programming task is in Assembly language? 

13. What percent of the new or modified code must be storage-optimized?. 


Fig. 6. B,ank form for software coal modal input! 
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14. What percent o£ the new or mocUCled code »u«t he timing-optimized? — 

15. What percent of the total programming task ie 'easy'? ,,,, 

16. What percent of the total programming task is 'hard'? ««« 

17. When is work to start, on the(PRD/FDP, SRD, SDD)7 _ 

18. What percent of the total program reguirementa are well established, 
stable, and will not be altered before delivery? 

19. What percent of the requirements ate likely to change slightly before 
delivery, but will do so under baseline change control? 

20. What percent of the requirements ate likely to change mote drastically 
before delivery, but will do so under baseline control? 

21. Complexity of program functional tcquitementsUiigh, medium, low)? 

22. Expected user involvement in requirements definition 
(much, some, none)? 

23. Customer experience in application area (much, none, some)? 

24. Customer/implementor organizational interface complexity 

(high, normal, low)? . 

25. Interfaces with other SW development projects or organizations 
(many, few, none)? 

26. Efflcieney of implementing organisation (poor, ok, good)? 

27. Overall implementation personnel qualifications and motivation 

(low, average, high)? 

28. Percentage of programmers doing functional design who will also 

be doing development (<.25, 25-50 , >50) ? 

29. Previous programmer experience with application of similar or greater 
size and complexity (minimal, average, extensive)? 

30. What is the average staff experience# in years, obtained from work 
similar to that required in the task being estimated? 

31. Previous experience with operational computer to be used 
(minimal, average, extensive)? 

32. Previous experience with programming languagc(s) to be used 
(minimal, average, extensive) ? 

33. Use of top-down methodology (low, medium, high)? 

34. use of structured programmer team concepts (low, medium, high)? 

35 . Use of Structured Programming (low, medium, high) 7 


Fig. 6 (conid) 



36, U 0 e o£ deaign and code InaiwcUoneUow, Qh, peer}? ^ 

37, Clasiified aocueity environment for computer (yes, # no)? 

38, Hardware under concurrent development (much# some# none)? 

39, Percent of work done at primary development site 
{<70# 70-90# >90)? 

40, Development computer access mode (remote# scheduled# demand)? 

41, Percent of development computet access availability(<30, 30-60# >60)? 


42, Quality of SW development tools and environment(poor# ok# good)? 

43, Maturity of system and support software (buggy# ok, good)? 

Overall adverse constraints on program design 

(severe, average# minimal)? 

45. Is the program real-time# multi-task (chiefly# some# no)? 

46. SW to be adaptable to multiple computer configurations or environments 

(yes, , no)? — „ 

47. Adaptation required to change from development to operational 
environment (much, some# minimal)? 


Values to be used for planning arcs 
Kilo-lines of code- 
Effort (person-months); 

Duration (months) ; 

Average staff (persons) ; 

Is output to be saved in a file? 

(>lame of output file to be created; 

Schedule start date; 


Select desired outputs and output media, or enter RETURN only for 
defaults. Defaults are lA, 2A# and 3A. Choices are; 

l«Gantt Chart A-file 

2«PERT dat3, 132 width B»line printer 

3kPERT data, 80 width 

Choice (s) ; 


Fig. 6, (conid) 
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TITLE! . 

ECR/ECOi 

SUBSYSi 


CDE: 


PROG. ID.! ff HVP 
Dafce Estimated! /J 




Answer the following items to the be«'^t of your estimation. 

1. How much new code is to be produced (completely new modules)? ^ _ 

Maximum value, kilo-lines executable source (99ft confidence level)? 

Expected value, kilo-lines executable source? - !■ f . 

Minimum value, kilo-lines executable source (99% confidence level)? 1. / 

2. How much code exists in modules requiring modification? . ^ 

Maximum value, kilo-lines executable source (991 confidence level)? 

Expected value, kilo-lines executable source? a ■ A 

Minimum value, kilo-lines executable source(99% confidence level)? • 3 

3. How much code will be deleted from these existing modules? 

Maximum value, kilo-lines executable source(99% confidence level)? 

Expected value, kilo-lines executable source? * 3 

Minimum value, kilo-lines executable source(99t confidence level)? 

4. How much code will be added to these existing modules? i. 

Maximum value, kilc. lines executable source(99% confidence level)? __ IZ 

Expected value, kilo-lines executable source? ;.M 

Minimum value, kilo-lines executable source(99% confidence level)? • V 

f. How much code will be changed in other ways in these modules? . 

Maximum value, kilo-lines executable source(99% confidence level)? * 
Expected value, kilo-lines executable source? * ▼ 

Minimum value, kilo-lines executable source (99% confidence level)? ‘7 

6. How much code will be deleted as entire modules from existing code? j 

Maximum value, kilo-lines executable source (99% confidence level)? /■ ▼ 

Expected value, kilo-lines executable source? bji 

Minimum value, kilo-lines executable source(99% confidence level)? bl 

7. How much of the remaining existing code must be retested? 

Maximum value, kilo-lines executable source (99% confidence level)? *• J 
Expected value, kilo-lines executable source? /■ t 

Minimum value, kilo-lines executable source (99% confidence level)? . /• y 

8. Expected percentage of code to be developed actually delivered aLOCI 

(0-90, 91-99, 100)? ir'jy 

9. How many different kinds of input/output data items per 1000 lines of . _ 

new or modified code ( >60, 16-80, 0-15)? 

10. Overall complexity of program and data base architecture 
(high, medium, low)? 

11. Complexity of code logical design (high, medium, low)? 

12. What percent of the programming task is in Assembly language? ^ 

13. What percent of the new or modified code must be storage-optimized? ^ 


Fig. 7. Example of input form usage 
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14. 

15. 

16. 

17. 

18. 

19. 

20 . 

21 . 

22 . 

23. 

24. 

25. 

26. 

27, 

28. 

29. 

30. 
31 

32. 

33. 

34. 

35. 


What percent o£ the new or modified code must be timing-optimized? 




What percent of the total programming task is 'easy'? 
What percent of the total programming task is 'hard'? 
When is work to start, on the(FRD/FDD, SRD, SDD)? 





What percent of the total program requirments are well established, ^ 
stable, and will not be altered before delivery? • ” 


What percent of the requirements are likely to change slightly before 
delivery, but will do so under baseline change control? ! O 


What percent of the requirements are likely to change more drastically 
before delivery, but will do so under baseline control? « 


Complexity of program functional requirements (high, medium, low)? 




Expected user involvement in requirements definition 
(much, some, none)? 

Customer experience in application area (much, none,. some)? 


i ftti * 


Customer/implementor organizational interface complexity 
(high, normal, low)? 




Interfaces with other SW development projects or organizations 
(many, few, none)? 

Efficiency of implementing organization (poor , ok, good)? 

Overall implementation personnel qualifications and motivation 
(low, average, high)? 

Percentage of programmers doing functional design who will also 
be doing development (<25 , 25-50, >50)? 


jLaja^ 




Previous programmer experience with application of similar or greater . 

size and coirplexity(minimal, average, extensive)? 


What is the average staff experience, in years, obtained from work 
similar to that required in the task being estimated? 


Previous experience with operational computer to be used 
(minimal, average, extensive)? 




Previous experience with programming language (s) to be used 
(minimal, average, extensive)? 

Use of top-down methodology (low, medium, high)? 

Use of structured programmer team concepts(low, medium, high)? 

Use of Structured Programming (low, medium, high)? 



Fig. 7 (conM) 
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3C. Cse of design and code inspectionsdoy^ QAr peer)? 

37. Classified security environment for computer (yes, , no)? 

38. Hardware under concurrent development (much r some, none)? 

39. Percent of work done at primary development site 
(<70, 70-90, >90)? 


M 




40. Development computer access mode (remote, scheduled, demand)? 

41. Percent of development computer access availability(<30, 30-60, 

i 

42. Quality of SW development tools and environment (poor , ok, good)? 

43. Maturity of system and support softwnre(buggy, ok, good)? 




44. Overall adverse constraints on program design 
(severe, average, minimal)? 

45. Is the progr2un real-time, multi-task (chief ly, some, no)? 


-■ ( tfL- 


46. SW to be adaptable to multiple computer configurations or environments 
(yes, , no)? 

47. Adaptation required to change from development to operational 
environment (much, some, minimal)? 


-■aiA. 


Values to be used for planning are: 
Kilo-lines of code= 

Effort (person-months) : 

Duration (months): 

Average staff (persons) : 

Is output to be saved in a file? 

Name of output file to be created: 

Schedule start date: 


■ ik m Qt 



veeoi T 


Select desired outputs and output media, or enter RETURN only for 
defaults. Defaults are lA, 2A, and 3A. Choices are: 


Choice (s) : 


l«Gantt Chart 
2-PERT data, 132 width 
3»I>ERT data, 80 width 


A«f ile 

B*line printer 


I B if. 3 A 


Fig. 7 (contd) 
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TITLE; VERSION CONTROL EDITOR CDE; Angus Day 

ECR/ECO; e80.I76 PROG. ID.; HUP-D2-OP-D. 2 

SUDSYS; X21.6 Date Estimated; 14NOVBO 

Model Data Version 1.3 31OCT80 


Answer the following items to the best of your estimation. 

1. How much new code is to be produced (completely new modules)? 

Maximum value, kilo-lines executable source (99% confidence level)? 3.5 

Expected value, kilo-lines executable source? 3.3 

Minimum value, kilo-lines executable source (99% confidence level)? 3.1 

2. How much code exists in modules requiting modification? 

Maximum value, kilo-lines executable source(99% confidence level)? 6.9 
Expected value, kilo-lines executable source? 6.6 

Minimum value, kilo-lines executable source (99% confidence level)? 6.3 

3. How much code will be deleted from these existing modules? 

Maximum value, kilo-lines executable source (99% confidence level)? .4 

Expected value, kilo-lines executabie source? .3 

Minimum value, kilo-lines executable source(99% confidence level)? .2 

4. How much cod’i will be added to these existing modules? 

Maximum value, kilo-lines executable soutce(99% confidence level)? .7 

Expected value, kilo-lines executable source? .6 

Minimum value, kilo-lines executable source(99% confidence level)? .4 

5. How much code will be changed in other ways in these modules? 

Maximum value, kilo-lines executable source(99% confidence level)? 1.2 

Expected value, kilo-lines executable source? .9 

Minimum value, kilo-lines executable source (99% confidence level)? .7 

6. How much code will be deleted as entire modules from existing code? 

Maximum value, kilo-lines executable source (99% confidence level)? 1.4 

Expected value, kilo-lines executable source? 1*3 

Minimum value, kilo-lines executable source (99% confidence level)? 1.1 

7. How much of the remaining existing code must be retested? 

Maximum value, kilo-lines executable source(99% confidence level)? 2.1 

Expected value, kilo-lines executable source? 1-9 

Minimum value, kilo-lines executable source(99% confidence level)? 1.5 

8. Expected percentage of code to be developed actually delivered 

(0-90, 91-99, 100)? 91-99 

9. How many different kinds of input/output data items per 1000 lines of 

new or modified code(>80, 16-80, 0-15)? 16-80 

10. C/erall complexity of program ar>d data base architecture 

(high, medium, low)? MEDIUM 

11. Complexity of code logical design (high, medium, low)? LOW 

12. What percent of the programming task is in Assembly language? 9 

13. What percent of the new or modified code must be storage-optimized? 9 


Pig, 8. Hard copy formal input paramatar racord 
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What peccent o£ thp new ot mocUCied code must be uiming-optlmiBed? 

What peccent ol; the total pcogcamming task le 'easy'? 

What peccent o£ the total pcogcanuiiing task is 'hard'? 

When is work to stact, on the(rRD/PDD, SRD, SDD)? 

What percent o£ the total program requirmonts will bo established 
and stable before design f and will not bo altered before delivery? 


FRD/PDD 


What percent o£ the coquicomonts are likely to change slightly before 
delivery, but will do so unde." baseline change control? 10 

What percent o£ the requirements ace likely to change more drastically 
before delivery, but will do so under baseline control? 5 

Complexity of progcani functional requicemonts (high, medium, low)? LOW 

Expected user involvement in coquicomonts definition 

(much, some, none)? MUCH 

Customer experience in application area (much, none, some)? SOME 

Customer/implomontoc organizational interface complexity 

(high, normal, low)? NORMAL 

Interfaces with other sw development projects or organizations 

(many, few, none)? PEW 

Efficiency of implementing organization (poor , ok, good)? GOOD 

Overall implementation personnel qualifications and motivation 

(low, average, high)? HIGH 


Percentage of programmers doing functional design wlio will also 
be doing development (<25, 25-50, >50)? 

Previous pcogc'"-«imer experience with application of similar or greater 
size and complexity (minimal, average, extensive)? 

What is the average staff experience, in years, obtained from work 
similar to that required in the task being esti.,iated? 

Previous experience with operational computer to be used 

(minimal, average, extensive)? m: 

Previous experience with programming language (s) to be used 
(minimal, average, extensive)? M: 

Use of top-down methodology (low, medium, high)? 

Use of structured programmer team concepts (low, medium, high)? 

Use of Structured Programming (low, medium, high)? 


25-50 


Pig, 8 (contd) 
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36. Use o£ design and code inspections(low, QA, peer)? QA 

37. Classified security environment for computer (yes, , no)? NO 

38. Hardware under concurrent development (muc)i, some, none)? NONE 

39. Percent of work done at primary development site 

(<70, 70-90, >90)? 70-90 

40. Development computer access mode (remote, scheduled, demand)? DEMAND 

41. Percent of development computer access availability ( <30, 30-60, >60)? 30-60 

42. Quality of SW development tools and environment (poor , ok, good)? OK 

43. Maturity of system and support software(buggy, ok, good)? OK 

44. Overall adverse constraints on program design 

(severe, average, minimal)? MINIMAL 

45. Is the program real-time, multi-task (chiefly , some, no)? NO 

46. SW to be adaptable to multiple computer configurations or environments 

(yes, , no)? NO 

47. Adaptation required to change from development to operational 

environment(much, some, minimal)? MINIMAL 


Fig, 8 (contd) 
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Estimated Overall Parameters! 

+l-slgma 

Adjusted [lines o£ code* 6182 SLEC 
6280 6085 

Effort* 26.5 person-months 
45.8 15.3 

Staff productivity* 233 SLEC/staf f-month 
404 135 

Duration* 15.7 months 
Ib.O 12.9 

Avg. Staff* 1.7 
2.9 1.0 

Documentation* 537 pages $16. IK 
645 448 $19. 4K 

Computer CPI) time* 319 hours $0.0K 
478 212 $0.0K 


•average value 


-1-sigma 


$13. 4K 
$0.0K 


Use these figures to arrive at Effort, Duration, and Staffing 
requirements. Include factors to provide acceptlble risk 
and confidence levels. 

Values specified ate: 

Kilo-lines of code* ® 

Effort (person-months) : - 

Duration (months): ^ 

Average staff (persons) : 

Pot the numbers you have entered, a reasonableness check indicates that 
the average project would produce 7303 lines of code, using 32 staff-months 
of resources and 16 months of duration, with an average staff of 2 persons, 
for a productivity of 228 SLEC/staf f-month. 

The level of confidence in delivering 6182 lines of code, 
on-time and within resources* 33 %. 

Is output to be saved in a file? 

Name of output file to be created: VCI 

Schedule start date: 17NC 

Select desired outputs and output media, or enter RETURN only for 
defaults. Defaults are lA, 2A, and 3A. Choices ate: 


l=Gantt Chart 
2=PERT data, 132 width 
3=PERT data, 80 width 


A=f ile 

Bsline printer 


Choice (s) 


Fig. 9. Output of SWAG OBtimator using the "typical software 
project" parameters 
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Fig.10. Full PERT/CPM««orfc breakdown structure and scl 
table output of the software cost model 
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PAGE X 

1 TITLES VERSION CONTROL EDITOR 



CDE; Angus Day 

1 

1 ECR/ECOs 080.176 


PROG 

ID. ; HUP-D2-OP-D 

.2 1 

1 SUBSYSs X21.6 


STATUS AS OP; 14NOV80 

1 

i CODE 

1 

: TASK : WHO : EPP t E-START s D-PINSH : PLT| 

^ 1 

*0. 

START 

• 

» 

0 

17NOV80 ; 17NOV80 

01 

*1. 

Sys Plans, Reqts, & Design 

‘ 

0 

9JAN81 t 9JAN81 

01 

* 1.1 

Define Subsys Reqts 

1 

15 

17NOV80 ; 3DEC80 

01 

* 1.2 

FRD 

1 

0 

6DEC80 : 8DEC80 

01 

i X • 2 • X 

Wcite all sections 

1 

4 

17NOV80 ! 5DEC80 

91 

* 1.2.2 

Edit and celease FRD 


2 

5DEC80 : 8DEC80 

01 

* 1.3 

Level B Review 


3 

8DEC80 ; 10DEC80 

01 

* 1.4 

Define Sys Acchitectuce 


18 

10DEC80 ; 31DEC80 

01 

* 1.5 

FDD 


0 

7JAN81 ; 7JAN81 

01 

1 1.5.1 

Write all sections 


4 

10DEC80 ; 6JAN81 

121 

* 1.5.2 

Edit and release 


2 

6JAN81 : 7JAN81 

01 

* 1.6 

Level C Review 


3 

7JAM81 ; 9JAN81 

01 

*2. 

SW Planning and Reqts 


0 

16PEB81 s 16PEB81 

01 

* 2.1 

Define Software Reqts 


25 

9JAN81 ; 4FEB81 

01 

* 2.2 

SRD 


0 

12PEB81 ;• 12FEB81 

01 

1 2.2.1 

Write all sections 


4 

9JAN81 : 11FEB81 

211 

* 2.2.2 

Edit and release 


2 

11PEB81 : 12FEB81 

01 

* 2.3 

Level D Review 


2 

12FEB81 : 16FEB81 

01 

*3. 

SW Architecture and Design 


0 

6APR81 ; 6APR81 

01 

* 3.1 

Define SW architecture 


31 

16FEB81 : 19MAR81 

Q| 

* 3.2 

SDD 


0 

2APR81 ; 2APR81 

01 

1 3.2.1 

Write all sections 


4 

16PEB81 : 1APR81 

301 

* 3.2.2 

Edit and release 


2 

1APR81 : 2APR81 

01 

1 3.3 

System Interface Design 


22 

16FEB81 : 1APR81 

201 

* 3.4 

Level E Review 


2 

2APR81 ; 6APR81 

01 

*4 . 

SW Detailed Design & Prod 


0 

22DEC81 : 22DEC81 

01 

1 4.1 

SSD 


0 

23FEB82 ; 11MAR82 

121 

1 4.1.1 

Write Sections 1,2,3 


6 

6APR81 ; 18DEC81 

1751 

* 4.1.2 

Write Section 4 


18 

6APR81 ; 24APR81 

0| 

1 4.1.3 

Write Section 5 


43 

24APR81 : 18DEC81 

1421 

1 4.1.4 

Write Section 6 


4 

6APR81 ; 18DEC81 

1761 

1 4.1.5 

Write Section 7 


9 

6APR81 ; 18DEC81 

1731 

1 4.1.6 

Edit and release 


6 

X8PEB82 : 11HAR82 

121 

1 4.2 

SOM 


0 

22FEB82 ; 11MAR82 

131 

* 4.2.1 

Write preliminary draft 


8 

24APR81 : 4MAY81 

01 

1 4.2.2 

Complete all sections 


9 

2UUN81 ; 18DEC81 

1331 

1 4.2.3 

Edit and release 


4 

18FEB82 ; 11MAR82 

13 1 

* 4.3 

High-level Design Review 


2 

29MAY81 : 2JUN81 

01 

* 4.4 

Module Production & Integ 


0 

18DEC81 : 18DEC81 

01 

* 4.4.1 

Executive and control 


18 

4MAY81 : 29MAY81 

0| 

^ 4.4.2 

I/O Modules 


18 

2JUN81 ; 26JUN81 

01 

* 4.4p3 

1 

Interface handlers 


18 

26JUN81 ; 23JUL81 

0| 

. _ 1 

1 ^ ~ 1 


Fig. 11 . Short-form output of the PERT/CPM WBS schedule data 
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PAGE 2 

1 . . _ , 

1 TITLES VERSION CONTROL EDITOR 

CDE: Angus Day 

1 

1 

1 ECR/ECO: e8Q.176 

PROG. ID.: HUP-D2-0P-0. 

2 1 

1 BUBSTSs X2I.6 

STATUS AS OF: 14NOV80 

j 

1 CODE 

TASK 

WHO 

EFF : E-START : 

L-FINSH : 

FLTI 

* 4.4.4 

Function A 


18 : 23JUL81 : 

17AUG81 : 

ol 

* 4.4.5 

Function B 


18 : 17AUG81 : 

11SEP81 : 

01 

* 4.4.6 

Function C 


17 ; 11SEP81 

60CT81 

01 

* 4.4.7 

Function d 


17 : 60CT81 

290CT81 

01 

* 4.4.8 

Function E 


17 : 290CT81 

23NOV8X 

01 

* 4.4.9 

Function F 


17 : 23NOV81 

18DEC81 

01 

1 4.5 

Special Tasks 


0 : 10JUN81 

18DEC81 

1321 

1 4.5.1 

Support software 


12 : 2JUN81 

X8DEC81 

1321 

1 4.5.2 

Other 


6 : 2JUN81 

X8DEC81 

1351 

* 4.6 

Acceptance Readiness Rvw 


2 : 18DEC8X 

22DEC8X 

01 

*5. 

SW Test and Transfer 


0 : 18MAR82 

18MAR82 

01 

* 5.1 

Verification tests 


28 : 22DEC81 

1FEB82 

01 

1 5.2 

Contingency 


25 : 9APR81 

11MAR82 

2181 

1 5.3 

STT 


0 ; 19FEB82 

18MAR82 

191 

1 5.3.1 

Write all sections 


14 : 2JUN81 

1FEB82 

159! 

1 5.3.2 

Edit and release 


2 : 18FEB82 

11MAR82 

141 

* 5.4 

Acceptance tests 


20 : 1FBB82 

18FEB82 

01 

* 5.5 

Demonstration tests 


22 : 18FEB82 

1XHAR82 

01 

* 5.6 

Transfer, cde to COE 


7 : 11MAR82 

18MAR82 

01 

16. 

Mgt Tasks and Milestones 


0 : 16DEC80 

18MAR82 

3131 

1 6.1 

CDE Activities 


37 : 17NOV80 

18MAR82 

3131 

* 6.2 

Develop prelim budget 


3 : 3DEC80 

5DEC80 

01 

* 6.3 

Develop Sys Impl Plan 


3 : 31DEC80 

6JAN81 

01 

* 6.4 

Draft Software Impl Plan 


6 : 4FEB81 

11FEB81 

01 

* 6.5 

Revise Impl Plan 


12 : 19MAR81 

1APR81 

01 

1 6.6 

QA Audit 


26 : 18FEB82 

18MAR82 

61 

♦FINISH 
1 _ 



0 : 18MAR82 

18MAR82 

01 



Fig. 11 (contd) 
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Appendix A 

DSN Software Cost Model Factors 


This Appendix contains a listing o£ the standard factor 
file accessed by the software model. A correspondence between 
factors on the file and those appearing in formulas herein 
appears below: 


FILE AND PROGRAM 

mn'ej^oniS report symbol 


NEWPAC 

1 (normalized) 

CHMFAC 

b 

ADLPAC 

c 

CHLFAC 

d 

DLNFAC 

e 

DMDFAC 

g 

RTS FAC 

h 

LLEV 

^HOL 

LADJ 

^assy 

CADJ 

^c-cri t 

TADJ 

^t-cr i t 

EADJ 

f 

easy 

HADJ 

^hard 

BADJ 

f 

base 

MADJ 

^many 

FADJ 

^free 

* Factors in the file used by the model 
symbol in this report. 

not given a specific 



FILE AND PROGRAM 

mJj'EmSniO' 

REPORT SYMBOL 

SADJ 

^exp 

FULLUP 

^full-up 

KSLECPM 

Pl 

A 

a 

AWFFAC 

^wf 

EIFAC 

^sigma 

DFAC 

'^1 

DEXP 

^t 

TIPAC 

* 

PPKSLEC 


AD 

'^doo 

PGCOST 

* 

DIPAC 

* 

CFAC 


AC 

^cpu 

Cl FAC 

* 

CPTROOST 

* 

SIFAC 

* 

WTFAC 

'^1/2 

ATFAG 

W/K 

LOGRATIO** 

-l«gfPhi(i)/'’lo(i 


Factors in the file used by the model not given a 
specific symbol in this report. 

The i^OGRATIO designator does not appear in the file; 
however it is found as the numeric field following the 
3 ANSWER entries. 
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D6N SOnVlARE OOffl- STANEAFU) FACTOR FILE 


VERSION (VE»S$) , "Version 1.3 31OCT80" 

WORK DAYS PER NO (DAYSPERNO) ,20 

HDR FIELD 1 (HFL1$) , "TITLE; " 

HDR FIELD 2 (HE12$) ,"0)E; " 

HDR FIELD 3 (HEL3$) /EOVEICO; " 

HDR FIELD 4 (HFL4$) ,"PROG, ID.; " 

HIR FIELD 5 (HFI5$) ,"SUBSYS; " 

CLEAR SCREEN (CLS$) ,2,27,43 

NEW CODE FACTOR (NEWFAC) ,1 

CHG MODULE FAC (CHMFAC) ,.27 

M)D LINES FAC (ADLFAC) ,.80 

CRG LINES FAC (CHLFAC) ,.24 

DEL LINES FAC (DLNFAC) ,-.15 

DEL tCDULE FAC (DMDFAC) ,.11 

RETEST FACTOR (FTSFAC) ,.17 

lANGUAGE LEy/EL (LLEV) ,2.4 

UV« ADJ FAC (LADJ) ,.82 

CAP ADO FAC (CADJ) ,1.01 

TIME ADJ FAC (TADJ) ,.72 

EASY AIXI FAC (EADJ) ,.8 

HARD ADO FAC (HADI) ,1.2 

BASLINE CHG FAC (BADJ) ,1.35 

MANY CHG BL FAC (MADJ) ,1.9 

FREE CHG FAC (FADO) ,2.3 

STAFF EXP ADJ FAC (SADI) ,.06 

FULL-UP TRNG FAC (FUIAUP) ,.4 

KSLBC/MD (KSLBCPM) ,.237 

DEFAULT «anU<:riVITY (PDEFLT) ,.2 

EFFIORT EXPOt-iiiNT (A) ,1 

WF MODEL EXPONENT (AWFFAC) ,1.95 

EFFORT STD DEV FAC (EIFAC) ,1.73 

DURATION FAC (DFAC) ,4.88 

DURATION EXP (DEXP) ,.356 

DUR STD DEV FAC (TIFAC) ,1.49 

PAGES DOC/KSLBC (PEKSLBC) ,120 

DOC EXPONENT (AD) ,.823 

COST PER EAGE (PGOOST) ,30 

DOC STD DEV FAC (DIFAC) ,1.2 

OOMPTR HRS FAC (CFAC) ,25.2 

CPTR TIME EXPOT (AC) ,.96 

CPTR TIM Sro DEV FAC (CIFAC) ,1.5 

OOMPTR HR COST (CPTRCOST) ,0 

STAFF STD DEV FAC (SIFAC) ,1.53 

HALF-TIME EFF. FACTOR (WTFAC) ,1.5 

PUTNAM KA/K FACTOR (ATFAC) ,.88 

VCS TASK SKIPS (SKIPS) ,0, 14, 21 

PR0MPT1 ," Expected value, kilo-lines executable source" 

PROMPT2 ," Maxiiman value, kilo-lines executable source (99% confidence level)" 

PROMPT! ," Minimtm value, kilo-lines executable source (99% confidence level)" 

PRCMPT4 ,"1. How much new code is to be produced (completely new modules)?" 

PRCMPT5 ,"2. How much code exists in modules requiring modification?" 
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DSN SOFTOARE COST K)DEL OTAIOARD FADTOR FILE 


F!KMFr6 r”3. How much code will be deleted from these existing modules?” 

FRGHFr; ,”4. How much code will be added to these existing modules?” 

FRCMPF8 ," 5 . How much code will be changed in other ways in these modules?” 

PRCMPT9 ,”6. How much code will be deleted as entire modules from existing code?” 

PROMWIO,”?. How much of the remaining existing code must be retested?” 
FRQHPF11,”12. What percent of the prograraning task is in Assembly l 2 uiguage” 
PRDMPri2,"13. W»t percent of the new or modified code must be storage-optimized” 

FRCNFT13;”14. What percent of the new or modified code must be timing-optimized” 

PRGMPT14f"15. What percent of the total programming task is 'easy'” 

PRCMPri5,”16. What percent of the total progr£mming task is 'hard'” 

PRCMPT16,”18. What percent of the total program requirments will be established 

and stable before design# and will not be altered before delivery” 

FRCMFri7#*19. What ^rcent of the requirements are likely to change slightly before 
delivery# but will do so under byline change control” 
roCMPrl8#”20. What percent of the requiranents are likely to change more drastically 
before delivery# but will do so under baseline control” 

PR0MPri9#"30. What is the average st 2 d;f experience# in years# obtained from work 
similar to that required in the task being estimated” 

HWMFI!20#”8. Expected percentage of code to be developed actually delivered 


ANSWERS, 0-90 # 91-99 #100 #- .511 

PRCKPT21,”9. How many different kinds of input/output data items per 1000 lines of 
new or modified code” 

ANSWERS, >80 ,16-80 ,0-15 ,-.548 

FRCMFT22,”1Q. Overall complexity of progran and data base architecture 


ANSWE3®, high, medium, low,-. 529 

reOMFr23f”ll. Complexity of code logical design” 

ANSWEItS , high , mediun# low , - . 32 4 
EROMPT24,”17. When is work to start, on the" 

ANSWERS, FRD/FDO, SRD, SDD, -1 .386 

PRCMPT25,”21. Complexity of progran fmctional requirements" 
ANSWERS, high , medium, 1<5W,- .7'^1 

PR0MPr26#”22. Expected user involvement in requirements definition 

•I 


ANSWERS , much , some , none ,-. 87 3 

PRQMPr27f''23. Customer experience in application area” 

ANSWERS , much , none , some ,-. 501 

FROHCT28,”24. Customer/implementor organizatioral interface complexity 

ft 

ANSWERS, high, normal, low, -1 .394 

PROMET29,"25. Interfaces with other SW develc^xnent projects or organizations 

9f 

ANSWERS,many ,few,none,- .405 

FRCMFT30,”26. Efficiency of implementing organization” 

ANSWERS , poor , ok , good ,-. 6 93 

FRGMFr31,”27. Overall implonentation personnel qualifications and motivation 

N 

ANSWERS, low, average, high, -1 .133 

jER 0MFT32,"28. Percentage of progranmers doing functional design who will also 
be doing develc^ment” 

ANSWERS , <25 , 25-50 , >50 ,-. 93 8 

FRCMFr33,"29. Previous programmer experience with application of similar or greater 



DSN SOnXARB OOOT M3DEL STANCARD FACTOR FILE 


size and complexity” 

ANSWERSfinininBl f averager extensivef-l . 033 

FRGMPr34r"31. Previous experience with operational computer to be used 

K 

ANSWERSrminimalraveragerextensiver-.759 

FRCMFT35r”32. Previous experience with programming language (s) to be used 

ANSWE3^rinininalraveragerextensiver~1.149 
ERaHPT36,”33. Use of top-down methodology" 

ANSWESSr low,mediumr high r- . 493 

PR0MPr37r"34. Use of structured programmer team concepts" 

ANSWQ^r .622 

PR0MPT38f"35. Use of Structured Programming" 

ANSWERS , low , mediumr high 577 

PRCMPr39,"36, Use of design and code inspections" 

ANSWERS, loWrQAr peer r- . 432 

PR0MIT40r"37. Classified security environment for computer" 

ANSWERS,yes, ,nOf-.617 

PRGMPr41,"3B. Hardware under concurrent develc^nient" 

ANSWERS, much , some r none r 51 8 

ER0MP1’42,"39. Percent of work done at primary development site 

fl 

ANSWERS, <70 ,70-90 , >90 ,-l .147 

PR0MPT43,"40. Development cxmputer access mode" 

ANSWERS, remote, scheduled, demand, -.742 

FR0MPT44,"41. Percent of development computer access availability" 

ANSWERS, <30 ,30 -60 ,>60 ,-.718 

PR0MFr4S,"42. Quality of SW development tools and environment" 

ANSWERS,poor ,ok,good,- .693 

PRCMPT46,"43. Maturity of system and support software" 

ANSWERS,buggy ,ok,good,- .693 

PR0MPT47,"44. Overall adverse constraints on program design 

m 

ANSWERS , sever e , average , minimi ,-. 56 8 
PR0MPP48,"45. Is the progrcin real-time, multi-task" 

ANSWERS,chief ly , some , no , -2 . 3 

PRGMPr49,"46. SW to be adaptable to multiple computet configurations or environments 

•I 

ANSWERS,yes, ,no,-.405 

PRCMPT50,"47. A^ptation reqviited to change from development to operational 
environment" 

ANSWERS , much , some , mininel ,-. 405 
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Appendix B 

DSN Software Cost Model Standard 
Work Breakdown Structure Skeleton 


The staiularcl Work IJreakdown Struclure (WBS) skeleton is contained In a flic defining 
a R-RT plan of a typical software project. Effort and duration of each task in the WBS 
skeleton are given in fractions of the total W and T determined by the program. 

The first record in the file is merely an identifier, announcing tlic WBS ver.sion number 
(displayed on tlie screen when the program starts). The remaining records are of the form 

(task code), (task title), (who field), (effort), (duration), (predecessor list), . (date) 

The (task code) and (task title) fields are strings, wiiiie (effort) and (duration) arc 
numeric (fractional values). The (who field) is not used in this version (it appears so as to 
be compatible with the PERT progr.am). The (predecessor list) is of the form 

(task code) 
or 

(task code), (predecessor list) 

The (predecessor list) may extend over several linos; the signal for the end of the list 
is tire period, llte (date) field is null; it also appears here to be compatible witii the PERT 
program. Wlien not null, it annminces to the PERT program an actual date that the task 
must complete. 
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